Data stores, or more particularly databases, generally store files of various forms or structures. Search programs, sometimes called search engines, allow users to use a query language to identify and retrieve these files or specific portions of files based on content-based search criteria.
Although search engines and query languages have conventionally been focused on text files, recent years have seen an increasing need to search other file types, particularly in software development contexts. Seminal examples of file types in the development context include bugs, links, and components. A bug is an abstract data element that refers to a problem report, malfunction, defect, or other related issue regarding software code. A link is a data element identifying a logical association between two or more other data elements or objects, for example two or more duplicate or dependent bugs. Component-type files generally include re-useable software objects, including, for example, binary code, HTML code, source code, and so forth.
Each of these file types often requires a specialized search engine, because they are disparate in form, content, and attributes, they are often stored in different databases, and users have different needs when searching these files than typical text files. Moreover, many of these search engines have a unique graphical user interface tailored to search its associated file types. Thus, for example, a user interface for searching bug files generally includes an arrangement of input fields, which is entirely different than those in an interface for searching component files. Because of their disparate input-field arrangements, these unique user interfaces force users to continually reorient themselves as they switch from interface to interface to initiate searches for desired files of different types.
Some interfaces, particularly OLE DB (Object Linking and Embedding Database) interfaces, provide a measure of commonness or congruence across distinct databases. However, these are limited to defining keyword searches, leaving the bulk of the disparate-interface problem unsolved.
Additionally, many of these user interfaces use different query structures, with each query structure optimized for a particular file type. To address this problem, many databases and associated search engines have begun “speaking” a common query language, known as SQL, which reduces the need for users to understand multiple query languages and formats. Although SQL (frequently read and pronounced as “se-kwel”) has a broad range of query properties for searching many file types, its universe of properties and types cannot be readily expanded. Thus, any given version of SQL cannot adapt to search new file types that would require or benefit from new query-language features or properties.
Accordingly, the present inventors identified an unmet need for adaptively configurable user interfaces for searching different types of data stores and an unmet need for a readily extensible or expandable query language.